1. Technical Field
The present invention generally relates to the field of data processing. More particularly, embodiments of the present invention relate to the acquisition and analysis of trace data.
2. Background Information
During the development of a computer program, it often is desirable to test the computer program by providing test data and then executing the computer program to generate test results. A user then may evaluate the test results and modify the computer program based upon the results. During this process, the user may desire to run at least a portion of the computer program several times to assist, for example, in isolating the suspected cause of an error. When, however, a computer program is very large or has a very long execution time, it may be impractical to replay the entire program for evaluation and debugging. Therefore, a technique called incremental replay was developed which allows a user to select and replay only a portion of the computer program's execution.
To provide effective support for debugging and testing computer programs, a replay apparatus must incur low setup and replay times, it must interfere with and slow down the program's execution as little as possible, and it must not require large amounts of data to be stored. Setup time is the time required to prepare for replay after an original program has been executed at least once. Replay time is the time required to actually re-execute the instructions associated with the desired portion of the computer program.
Some approaches minimize setup time while other approaches minimize replay time. During the setup time, variables or memory locations typically are set to values that are accurate for the portion of the computer program that is to be replayed. Typically, this practice includes providing, during or prior to replay, the same values to the memory locations that were present during the initial execution of the program.
Interference with the original (first executed) program often is caused by inserting instrumentation instructions into the original program to facilitate replay. If there are too many of such instrumentation instructions or if such instructions are too intrusive, then the original program may be slowed down too much during the initial execution or during the replay.
Because replay generally involves some storage during an initial execution of a program, as mentioned above, another consideration is the amount of data to be stored. Although enough data should be stored to accurately replay the desired portions of the original program execution, too much stored data will require excess storage resources as well as unnecessary overhead functions to manage the stored data.
One approach to incremental replay uses a virtual memory system of a computer to periodically trace, at fixed time intervals, the pages of the virtual memory system that were modified by a computer program since a previous checkpoint of the computer program. The term “trace,” as used herein, refers to storing data in a memory so that such data is available for later use, such as resetting variables and memory locations.
To restart the program's execution from an intermediate point requires that a replay tool search the stored trace to find the most recent trace of each page. Because checkpoints are taken at fixed time intervals, the system bounds replay time, i.e., the amount of time required to replay up to a desired portion of the original program execution. However, setting up the state for the replay may require searching through an entire trace file, which may involve significant time and resources. Although this approach is adaptive in that it traces only pages that have been recently written to, tracing the entire contents of pages that have been written to since the last checkpoint can require large amounts of storage.
Another approach to tracing is performed at compile-time of a program to determine what and when to trace. In particular, a pre-log on the entry of each procedure is written, with the pre-log containing the values of the variables that the procedure might possibly read. The pre-log allows a procedure to be replayed alone since the pre-log contains all variables necessary for the instructions of the procedure to properly execute. A post-log is written upon exit from the procedure, with the post-log containing the values of the variables that the procedure might have modified. The post-log allows the procedure to be skipped during replay since the post-log includes changes that the procedure might make.
Such a system may result in storing much more data than is actually required to facilitate replay, because the analysis performed at compile-time must be conservative to assure that any replay will be accurate. Additionally, tracing only at procedure entry and exit may incur a large amount of intrusion during the initial execution of the program, and does not guarantee that replay up to a desired portion of the execution will be attainable in a predetermined amount of time. For example, a loop that is iterated several times and includes a procedure call may result in many needless traces. Conversely, a very long procedure call may not be traced often enough to replay any part of the procedure within time constraints that are acceptable to a user.
Another system traces a “change set” before each statement or group of statements. The change set includes the values of the variables which might be modified by the statement or group of statements. A debugger then can backup execution over a statement by restoring the state from the associated change set. To bound the trace size, it is possible to store only the most recent change set for each statement. The system statically computes the change sets, and for programs that use pointers and arrays, the system must trace each such access. The system does not bound the time required to perform a replay, since it requires backing up to an instruction that is prior to the desired interval, and then progressing forward to perform the desired interval. This system is limited by its static nature, in that it may have to trace every array or pointer reference for example.
Another technique maintains a hierarchy of checkpoints, each checkpoint taken at successively larger time granularities, so that recent states can be reproduced relatively quickly while older states incur more delay. This technique also includes a virtual snapshot as an approach to check-pointing, in which only the elements of a checkpoint that differ from a previous checkpoint are saved.
U.S. Pat. No. 5,870,607 shows a method for selective replay of computer programs. A user can selectively reply portions of a computer program execution so that the entire program need not be run again to support further test and debug. A run-time instrumented version of the program is created by inserting special instructions into the original program. The run-time instrumented version is executed to create trace files of memory accesses and system calls as well as identification of interrupts.
U.S. Pat. No. 5,642,478 shows a distributed trace data acquisition system. An event data capture circuit is integrated into each processing node in a distributed multi-node system for capturing even data within each node under software control.
U.S. Pat. No. 6,314,530 shows a computer system having an on-chip trace memory having a plurality of locations for storing trace information that indicates execution flow in the processor.
Despite such advancements, conventional tracing techniques suffer from one or more disadvantages. For example, a common disadvantage of known tracing techniques is that the ability to review and modify customizing parameters is not supported.
The above description is based on the knowledge of the present inventors and not necessarily that known in the art.